REA(리버스엔지니어링애니씽)에 대해 알아보자 #3 실제 레딧 반응 분석 | 매거진에 참여하세요

1편은 REA(리버스엔지니어링애니씽)과 관련한 내용소개를 드렸습니다.

https://letspl.me/quest/2430/shortcut

2편은 REA의 실제 사례를 조사해봤습니다.

https://letspl.me/quest/2431/shortcut

마지막으로 개발자나 사용자들의 반응을 확인해보겠습니다.

REA가 공개된 이후 Reddit에서는 흥미로운 질문이 등장했습니다.

"이거 정말 되는 거야? 실제로 사용해 본 사람 있어?"

단순히 GitHub 스타가 많다는 사실보다 중요한 것은 실제 사용자들이 기존 프로그램을 분석하고, 그 결과를 활용해 무언가를 만들어냈는지입니다.

Reddit의 r/claude 관련 토론과 r/decomps의 REA 사용 경험을 살펴보면 상당히 현실적인 이야기들이 등장합니다.

1. "2년 동안 구현하려던 기능을 드디어 분석했다"

Reddit – I just reverse engineered a feature from a software I have been trying to mirror for the past 2 years

한 사용자는 2년 동안 구현하려고 시도했던 기능을 REA와 Claude를 이용해 분석했다고 이야기했습니다.

기존에는 특정 기능을 구현하기 위해 해당 소프트웨어의 비공개 SDK가 필요했습니다.

하지만 SDK를 제공받지 못했고, 결국 프로그램을 직접 분석하는 방법을 시도했습니다.

사용자는 바이너리를 분석한 결과, 다른 소프트웨어의 보조 앱에 구현된 기능이 어떤 방식으로 동작하는지 확인할 수 있었다고 설명합니다.

이후에는 다른 프로그램의 암호화 방식까지 분석해 보려고 한다고 이야기했습니다.

물론 이 사례는 사용자가 직접 공유한 경험이며, 분석 결과가 독립적으로 검증된 것은 아닙니다.

그럼에도 실제 프로그램의 기능을 분석해 기존에 구현하지 못했던 기능을 이해했다는 점에서 흥미로운 사례입니다.

2. "앱 제조사의 클라우드를 버리고 내 서버로 연결했다"

Reddit – Does this mean the end of enshittification?

이 사례는 개인적으로 REA의 가장 현실적인 활용 가능성을 보여준다고 생각합니다.

한 사용자는 REA와 Claude를 이용해 여러 스마트 기기의 Android 앱을 분석했다고 이야기합니다.

대상은 다음과 같은 기기였습니다.

• - Withings 스마트 체중계

• - 저렴한 스마트워치

• - TCL 에어컨

사용자는 이들 기기의 앱과 통신 프로토콜을 분석해 데이터를 자신의 홈 서버로 전달하도록 만들었다고 설명합니다.

그 결과 제조사가 제공하는 클라우드 서비스나 광고가 포함된 앱에 의존하지 않고, Home Assistant와 Grafana를 활용해

자신의 환경에서 데이터를 관리할 수 있게 되었다고 합니다.

이 사례에서 REA의 의미는 단순히 기존 앱을 복제하는 데 있지 않습니다.

이미 구매한 하드웨어를 제조사가 제공하는 앱과 서비스의 제약 없이 활용할 수 있도록 만드는 것입니다.

물론 이러한 작업은 기기별 프로토콜과 암호화 방식에 따라 난이도가 크게 달라지며, 모든 제품에서 가능한 것은 아닙니다.

3. "실제로 해보니 토큰을 엄청 쓰고, 결과물을 계속 수정하기도 어려웠다"

Reddit – r/decomps REA 사용 경험

긍정적인 사례만 있는 것은 아닙니다.

한 사용자는 Grok과 Cursor를 이용해 APK를 분석해 보았지만, 결과에 크게 만족하지 못했다고 이야기했습니다.

그 사용자가 언급한 문제는 크게 세 가지입니다.

• - 상당히 많은 토큰을 소비했다.

• - 처음 만들어진 코드가 이후 반복적인 수정과 개선을 진행하기 어려운 형태가 되었다.

• - 데이터 모델링에서 특히 문제가 발생했고, 프론트엔드 역시 사람의 상당한 가이드가 필요했다.

이 부분은 실제 개발에서 매우 중요한 문제입니다.

AI가 기존 앱의 기능을 분석하고 비슷한 코드를 만들어내는 것과, 그 결과물을 유지보수 가능한 제품으로 발전시키는 것은 별개의 작업이기 때문입니다.

특히 데이터 모델링은 단순히 화면을 비슷하게 만드는 것보다 훨씬 어렵습니다.

AI가 화면과 기능을 구현하더라도 데이터의 관계, 상태 변화, 예외 처리, 서버와의 통신 구조가 제대로 설계되지 않으면 실제 서비스로 발전시키기 어렵습니다.

즉, REA를 사용한다고 해서 개발자의 역할이 없어지는 것은 아닙니다.

4. "DOS 게임을 C 코드로 완전히 디컴파일하는 데 거의 일주일이 걸렸다"

Reddit – REA 사용 및 DOS 게임 디컴파일 경험

한 사용자는 오래된 DOS 게임을 분석해 C 코드로 재구성하는 작업을 진행했다고 이야기합니다.

처음에는 Claude가 약 한 시간 만에 Windows에서 실행되는 프로그램을 만들어냈지만, 이후 실제 디컴파일 작업은 훨씬 복잡했습니다.

사용자의 후속 설명에 따르면 완전한 C 코드 형태의 디컴파일에는 거의 일주일이 걸렸고, Claude의 주간 사용량 한도를 상당히 초과했다고 합니다.

API를 이용해 동일한 작업을 수행했다면 비용이 1,500달러 이상 발생했을 것이라는 추정도 공유했습니다.

여기서 중요한 점은 실행 가능한 프로그램을 만드는 것과 원본 프로그램을 완전히 디컴파일하는 것은 서로 다른 작업이라는 것입니다.

기존 DOS 게임을 Windows에서 실행하도록 만드는 것은 비교적 단순한 호환성 작업일 수 있습니다.

반면 수만 개의 함수로 구성된 게임을 분석하고 C 코드로 재구성하는 것은 훨씬 큰 작업입니다.

이 사례는 REA가 가능한 작업의 범위를 보여주는 동시에, 그 작업에 필요한 시간과 비용이 얼마나 커질 수 있는지도 보여줍니다.

5. "Claude는 거부했지만 다른 모델은 분석했다"

Reddit – REA와 Claude의 안전 정책 거부 논쟁

REA 사용자들이 가장 많이 언급하는 문제 중 하나는 AI 모델의 안전 정책입니다.

한 사용자는 Claude에게 REA 분석 보고서를 작성하도록 요청했지만, 작업 도중 안전 정책에 의해 거부되는 경험을 공유했습니다.

반면 같은 토론에서 다른 사용자는 GLM 계열 모델이 충분히 괜찮은 분석을 수행했다고 이야기했습니다.

Qwen 계열 모델이나 로컬 모델을 활용해 오래된 게임을 분석했다는 경험도 등장합니다.

또 다른 Reddit 사용자는 자신의 Windows 크래시 덤프를 분석하기 위해 Claude를 사용했지만 거부당했고,

다른 모델을 이용해 문제를 진단했다고 이야기했습니다.

이러한 경험은 REA의 성능을 평가할 때 중요한 요소입니다.

REA 자체가 분석을 수행하는 AI 모델은 아니기 때문에, 실제 결과는 다음 요소에 영향을 받습니다.

• - 어떤 AI 모델을 사용하는가?

• - 해당 모델이 리버스 엔지니어링 작업을 허용하는가?

• - 모델이 분석 도구의 결과를 얼마나 정확하게 해석하는가?

• - 얼마나 많은 컨텍스트와 토큰을 사용할 수 있는가?

• - 분석 대상 프로그램이 얼마나 복잡한가?

따라서 REA의 결과가 좋지 않았다고 해서 반드시 REA 자체의 문제라고 볼 수는 없습니다.

반대로 다른 모델에서 성공했다고 해서 REA가 모든 모델에서 동일하게 작동한다고 보장할 수도 없습니다.

마지막으로 Reddit 반응을 종합하면

REA를 직접 사용한 사람들의 반응은 상당히 현실적입니다.

결국 Reddit 사용자들의 경험에서 가장 중요한 결론은 다음과 같습니다.

REA는 실제로 기존 프로그램을 분석하고 새로운 기능을 구현하는 데 활용할 수 있지만, 그것이 곧 완성된 소프트웨어를 자동으로 복제할 수 있다는 의미는 아닙니다.

실제로 작동하는 기능을 분석하는 것은 가능해졌지만, 그 결과를 유지보수 가능한 제품으로 발전시키는 과정에서는

여전히 데이터 모델링, 아키텍처 설계, 테스트, 사람의 검증이 필요합니다.